|
|
|
|
|
|
|
Methods are nicely encapsulated series of code instructions that enable access to implemented behavior. Public methods enable external clients access to publicly known services, whereas private methods help public methods provide those services. In defining public methods, you'll need to review the specification for the expected class behavior, as documented in artifacts such as class diagrams and in interaction diagrams such as sequence diagrams and collaboration diagrams. In defining private methods, look for opportunities to break up numerous lines of code in public methods. For example, in the preceding paragraph, you saw two private methods that avoided the use of a potentially long and complex If Then statement body. Some private methods will already be defined in the design diagrams mentioned earlier. |
|
|
|
|
|
|
|
|
Defining Accessors and Mutators |
|
|
|
|
|
|
|
|
Defining accessors (get property values) and mutators (set property values) is simpler than defining regular methods. For every property (or attribute) a class has, you can create a getProperty method and a setProperty method. However, be careful. If you have a class that has nothing but accessors and mutators, you might potentially violate encapsulation because other classes might behaviorally use those methods in ways that could signal a lost method That is, a method of a client object could have a method that manipulates the server object's property in a way that would make that method a candidate for the server object. For instance, referring to Listing 4.1, assume that the adjustBalance method of theBasicPersonalCheckingAccount object had been designed into the theDeposit object. Also assume that an accessor, getCurrentBalance, and a mutator, setCurrentBalance, are new methods for the theBasicPersonalCheckingAccount object. Now that the theDeposit object has the adjustBalance method, it would simply call getCurrentBalance of theBasicPersonalCheckingAccount object, increase it by the value of Amount, and call theBasicPersonalCheckingAccount.setCurrentBalance to assign the new value. In this case, having the accessor and mutator helps to violate encapsulation by having a foreign object manipulate the owning object's properties. In many cases, however, having accessors and mutators is okay for statistics and totaling or for listing values of a collection of the same type of objects for users to view. |
|
|
|
|
|
|
|
|
By now, you have some familiarity with subsystems. Subsystems provide an opportunity to group classes together to carry out some major chunk of an application's behavior. The logical representation of a subsystem is called a category, although this sometimes |
|
|
|
|
|